Scenario Evolution: A Closer View on Relationships

In this article we show the results of an extensive research on scenario evolution. We investigated twelve case studies spanning over 200 scenarios that contained over 800 episodes. The research aimed at capturing data on scenario evolution in order to confirm previous results and to elicitate the requirements for a scenario evolution support environment. Our findings are organised in a three tier framework, that deals with scenario evolution in the process, product and instance levels. In this article we concentrate on the product and instance levels showing scenario relationships. Scenarios do not exist in a vacuum, they are connected to other scenarios in an intricate and complex network of relationships. We provide a taxonomy for classification and heuristics for the identification of scenario relationships. In the past years our group has been conducting research in the area of scenario evolution [Leite97, Leite97b, Breitman98]. Among other findings, we proposed a framework that models scenario behavior during the software development process. A series of operations were unveiled, showing that scenario evolution is very complex. The process of versioning is very fuzzy, scenarios are constantly merging and splitting, making traceability very difficult. In Figure 2 we attempt to show this aspect of scenario evolution. Figure 1 – a closer view of scenario evolution within the baseline Scenario evolution is not a trivial process. It goes beyond keeping track of new versions. It requires planning the use of a strategy that allows for the capturing and storing of evolution related information. We understand scenarios evolve in a two orthogonal axis. The first one is parallel to the software process. As development goes along we generate different scenario configurations, e.g., requirements scenarios, design scenarios and implementation scenarios. The second axis is maintenance. It reflects the everlasting versioning process the scenarios undergo. Even after an artifact is delivered, e.g., the requirements scenarios, the set continues to evolve. It is a well known fact that requirements change through development [Lehman80] and changes on further development stages may affect previous ones. From an evolutionary perspective, two issues stand out. First is the ability to determine the state of affairs in the scenario baseline at any given time in development. One has to be able to retrieve a configuration of scenarios with its relationships. We call this the snapshot view. It shows how the scenarios are connected and the sequence in which they should happen. This view is represented through a graph that explicits the relationships among scenarios. In other words this is the what, which scenarios are present in a given configuration and the way these are related. The second issue is understanding how this configuration came to be. We want to capture the history of operations that changed the baseline so that it came to a specific configuration. This is the how, the rationale for change that describes the reasons why a set of scenario attained some specific configuration. It is also necessary to keep a log of the operations that have been applied, e.g., split and merge, so that we can backtrack the information to previous versions. In this paper we tackle these issues by presenting a framework that explains scenario evolution in those dimensions. We focus on the taxonomy and identification of scenario relationships. The determination of the relationship graph is the first step in the process of scenario evolution. As a result of our work we understood that scenario evolution can be described by a set of operations that transform scenarios over time. Those operations are intimately related to the way scenario are interconnected. Scenario relationships provide the integrity restrictions for the application of any given operation. For instance if there is a scenario that relates to other scenarios as a pre condition (relationship), this scenario should not be Excluded (operation) from the set. All of our results are anchored in the data obtained from twelve case studies that were conducted in the past two years in both Brazil and Argentina. A total of 236 scenarios were investigated spanning over 800 episodes. Table I details the numbers. Please note that we included the number of relationships among scenarios for each case study. In the next two sections we provide an overview of the scenario evolution framework and detail the method used on the case studies. The following section details the relationships found, provides the heuristics for relationship detection and shows examples of relationship graphs. The last three sections present a discussion over related work, future research and the conclusions. Case Study number of scenarios number of episodes number of relationships Case Study I academic management 39 205 38 Case Study II Library system 20 98 19 Case Study III Library system Version1 4 26 4 Case Study IV Library system Version2 9 74 6 Case Study V Library system Version3 9 21 1 Case Study VI Gráfica Version1 13 45 16 Case Study VII Gráfica Version2 13 51 Case Study VIII Car Plan Version1 22 85 28 Case Study IX Car Plan II Version1 18 56 23 Case Study X academic management II Version1 26 23 16 Case Study XI academic management II Version2 28 85 29 Case Study XII academic management II Version3 35 104 49